Technicians located affected messages in VIPRE quarantine listings and in server‑side queues and released legitimate items so they delivered to recipients. Repeatedly held senders or domains were added to VIPRE gateway safe‑sender/allowlists or to mailbox‑specific allowlists; when third‑party platforms used variable sending IP ranges, platform IP ranges were added to allowlists. Equivalent allowlist or anti‑spam policy changes were recorded for Microsoft Defender/Exchange cases. When quarantines listed URL blocklist hits (for example calendar links) the blocklist entry was removed and the item released. Messages showing processing‑error strings (for example 'ProcessMessageFromQuercus') were identified from logged notes and released from the gateway.

Helpdesk staff released items on behalf of users when Quarantine Summary reports were view‑only and adjusted quarantine‑report recipient lists when necessary. To avoid bounces from forwarding quarantined messages into ticketing systems, items were released directly from the gateway rather than forwarded. Time‑sensitive one‑time verification messages that had expired by the time of release required re‑issuance by the sender. A small number of incidents showed errors when applying whitelist entries; those were handled by retrying administrative whitelist changes or applying alternative allowlist/policy updates so the sender could deliver. In some cases administrators added a sender to a safe list without releasing historical quarantined items at the user's request; those requests and actions were logged.

Domain‑wide whitelisting requests that were refused on security or data‑protection grounds were declined or replaced with limited sender‑level or mailbox‑specific allowlisting and the requester was informed. Where allowlisting proved insufficient or inappropriate, SOC/administrators adjusted quarantine/filter rules to stop internal or institution‑owned addresses being flagged as false positives. Technicians confirmed quarantined message identities (for example by requesting subject lines) when the quarantine UI omitted attachments and released items so attachments delivered. Actions and allowlist changes were logged with the responsible administrator.

Observed senders across incidents included commercial newsletter and transactional mailers (Mailjet, Amazon SES/Jotform, Ghost, dotdigital, Mandrill, HubSpot), marketing/ESP platforms (ExactTarget/SFMC), event/registration and application services (Cvent, On24, Sitefinity, Smapply), credentialing and notification services (Credly, Stripe, Handshake, OpenAI, Pearson, Perkbox), corporate partners and third‑party services (Randstad, IncisiveMedia, customervoice360, Hespa, BPP) and institutional senders. A small number of tickets recorded only a terse resolution note (for example 'Done'); relevant diagnostic and change logs were retained where available.

Multiple root causes for Scan-to-Mail failures were identified and resolved. A transient fault in the mail gateway that had been delaying Scan-to-Mail messages was corrected, which removed broad delivery delays. One affected printer/scanner lacked proper provisioning on the internal company portal and was re-provisioned so it received the IU_Internal Company Portal configuration and regained network connectivity on the Student WLAN. USB media visibility issues were traced to the device's Dell security USB policy and were remediated as part of the device fix, after which scanning and delivery functioned normally. Separately, an instance where scanned messages were flagged as phishing was caused by an incorrect sender address configured on a Canon ImageRUNNER Advance Dx C3926i; the messages were released from the anti-spam/quarantine and the device's sender address was corrected, which cleared the phishing/quarantine classification and restored delivery to users.

Specialist teams investigated delivery and banner issues by inspecting the SMTP envelope sender and upstream mail sources rather than the displayed From. They repeatedly found forwarding/relay/mail-flow rules, mailing-list software, or third-party services had rewritten the envelope-from or substituted system-generated senders; this caused messages to be quarantined, routed to Outlook 'Other', classified as Junk/Spam, or to display external-mail/phishing banners despite an internal-looking From address. Support used the true envelope sender, system-generated sender, or upstream mailing-list/ticketing server addresses (for example Freshdesk or Salesforce relay addresses) to locate and release quarantined items and then added those envelope addresses to allow-lists. In cases where messages had been moved to Deleted Items, investigators reproduced the behavior in Outlook Web and New Outlook, saved copies as a precaution, and recovered items from Recoverable Items to return them to users' mailboxes. Where third-party services triggered external-mail/phishing banners while using internal display-from addresses, teams coordinated with IT Security and updated external-mail/phishing-warning policies or mail-flow rules to exclude or internal-whitelist the affected domain or specific senders so internally-branded messages were not flagged. Attempts to release or allow-list initially failed until the forwarding chain or true envelope/system sender was identified. Subject-based whitelisting was not available in the examined platform controls. Systems and examples examined included Microsoft Quarantine, Office 365/Exchange mail flow and anti-phishing controls, Outlook Web and New Outlook clients, and upstream mailing-list management or third-party ticketing systems (Freshdesk, Salesforce).

The organisation performed a phased DMARC enforcement rollout for the primary domain. After ensuring third‑party senders were configured correctly, SPF/DKIM adjustments for CleverReach were completed first, and the DMARC pct was incrementally increased on scheduled dates (examples: 2023‑09‑11 0%→5%, 2023‑09‑18 5%→10%, 2023‑09‑25 10%→15%, 2023‑10‑09 15%→20%, 2023‑10‑25 20%→25%, 2023‑11‑14 25%→30%, 2023‑12‑06 onward) to move from p=none toward p=quarantine without causing widespread delivery failures. Later, when the policy was advanced from p=quarantine to p=reject, calendar RSVP/confirmation messages generated by Google began to bounce because Google‑authored responses used a Google domain in the Header From or otherwise failed DMARC alignment; Outlook‑generated RSVP messages did not fail because they were sent differently. No technical workaround was implemented to alter Google’s behavior; the team recorded a decision to leave the DMARC policy as configured and accept the observed bounce behavior rather than implement sender‑specific exceptions.

Investigations identified missing or incorrect outbound authentication (DKIM and SPF and related DNS records) for organisation domains used by third‑party senders as the root cause. Resolutions performed included obtaining provider‑supplied DKIM values or CNAME records (including cases where the provider generated the signing key), creating and publishing DKIM records, enabling DKIM signing on sender platforms where required (e.g., CMS/provider‑hosted senders), and expanding SPF TXT records to explicitly authorise each third‑party sender (Salesforce/Marketing Cloud, Prowly/Amazon SES, Frontify, SiteFusion and similar services). Additional MX/TXT records were added when providers required DNS verification (including examples involving PowerDMARC). After DNS records propagated, messages that had been rejected, quarantined, or marked as spam (including password‑reset and distribution‑list messages) were delivered instead of being blocked. Persistent Outlook client behaviour (external images blocked at display time) was observed as a separate client display effect alongside the authentication/deliverability issues.

The message was released from the quarantine by the IT/Email Administrator. The incident was documented as an automated outbound content/profanity policy; affected users were informed that removing or editing the offending word allowed resending, and that IT could release legitimately blocked messages on request.

Investigations reproduced delivery failures and quarantines and traced the root cause to attachment‑type policies enforced by recipients' mail filters (Exchange Online anti‑malware, institutional filtering and gateway spam‑quarantine services). Mail logs and quarantine notifications explicitly referenced blocked attachment types; one case confirmed that message size (observed limit 36,864 KB) was not the cause. Commonly blocked types included executables (.exe, .com), legacy Office documents (.doc, .xls) and macro‑enabled Office formats (.docm, .xlsm); .docx and .zip were sometimes allowed when legacy formats were rejected. Bounce and quarantine messages varied and in addition to 550 5.0.350 often showed Policy violation or SPF validation errors when messages were rejected. In at least one incident quarantines contained malicious attachments that had been spammed to many shared mailboxes and quarantine notifications omitted the sender address, which hindered recipient verification; HelpDesk/IT reviewed quarantined items and logs and confirmed the blocks were correct. Incidents were resolved by delivering content in allowed formats (for example converting problematic Word files to a different Word format or to .docx, or sending compressed archives) or by removing macros; when messages were legitimate, administrators reviewed and released or whitelisted senders or attachments or accepted files via alternative delivery portals such as a Safe Portal. Quarantined items determined to be spam or phishing were discarded and not released.

Investigations located affected messages using tenant quarantine searches (Defender/Exchange), Exchange mail traces/transport logs, Threat Explorer, Log Analytics, upstream ESP event logs (for example Amazon SES EmailEvents), and third‑party gateway quarantine consoles and logs (for example VIPRE/mailanyone). Quarantined or blocked items were released or unblocked to restore delivery; when tenant‑UI release actions showed pending or failed states, SOC or tenant administrators performed prioritized manual releases (including releases via VIPRE's quarantine console where applicable). Repeat or business‑critical flows were protected by tenant mitigations such as permanent‑release/allow rules, adding senders/domains to the tenant allowlist, and applying temporary release retention periods to keep released messages accessible during analysis. Tenant blocklist entries and specific blocked URLs were removed after false‑positive confirmation and affected messages were submitted to Microsoft and marked Clean when appropriate. Upstream blocking incidents were investigated using remote gateway bounce data (including SMTP 550 responses) and ESP event logs; remediation included allowlist/whitelisting discussions with remote ESPs when outbound mail was blocked. Duplicate quarantined items were identified as resends or large‑attachment retransmits and both copies were evaluated and released when appropriate. Where recipient‑side spam scoring contributed to delivery failures, message templates and content were reviewed and revised (for example removing excessive punctuation, avoiding ALL CAPS, and personalizing templated content), which correlated with reduced spam scores and improved inbox placement. Recipients were advised to add sending addresses to their personal allowlists when delivery depended on recipient‑level spam algorithms. Encrypted messages sometimes rendered quarantine previews unreadable (observed in VIPRE); these items were confirmed as expected encrypted/sensitive content before release. Phish‑alert escalations included legitimate account‑verification emails that were validated as genuine and closed.

Multiple root causes were observed and resolved. In cases where outbound encrypted replies failed because the correspondent’s S/MIME certificate or its issuer/root entries were missing or out-of-date in the sender’s Windows certificate store, the issue was resolved after the sender obtained the correspondent’s updated S/MIME certificates (example: VDA/arbeitsagentur.de) and the corresponding issuer/root certificates were installed into the Windows certificate store, restoring normal encrypted replies. In incidents where a mailbox or device had no S/MIME configuration after migration or provisioning, completing S/MIME setup on the user’s mailbox or on a new Windows 11 device enabled encrypted or partially encrypted sending. For users on personal or unmanaged Windows machines, IT-issued S/MIME certificates were delivered from the organization’s AD CS through the SAFE Portal and the user-installed certificate and password restored outgoing encryption capability; these cases also exposed that internally issued (AD CS) certificates were not publicly trusted by external recipients unless the trust chain was present on the device. Finally, when a sending address or domain lacked S/MIME provisioning (for example, the deine-weiterbildung.de address), provisioning S/MIME for that address/domain enabled encrypted sending to the Federal Employment Agency. Affected systems observed across incidents included Outlook on Windows (10/11), the Windows certificate store, AD CS/SAFE Portal distribution, and enterprise domain/certificate provisioning.

Support confirmed that it-helpdesk@iu.org was not active and supplied the correct reporting address (service@iu-it.org). The user was informed not to forward routine spam to IT and was shown that Outlook's right-click "Mark as Junk/Spam" was the appropriate reporting action for that message type. Staff also clarified that routine spam should not be characterized as affecting the whole organization; the user had archived the original message for possible future reference.

Investigations identified three mailbox-level delivery problems and the mitigations used. For unsolicited external marketing, spam and phishing that had been delivered despite perimeter controls, engineers either added offending senders to the mailbox-level blocked-senders list (Outlook), which removed messages from users’ inboxes and appeared to aid local spam learning, or added the senders to the organisation’s mail-filtering blocklist / created mail-filtering block rules to stop delivery to shared or department mailboxes. Administrators routinely requested a sample .eml when users could not locate messages; the .eml headers were used to identify the sender and create the appropriate block rule. Users were instructed to delete remaining offending messages and were given the organisation’s anti-spam/reporting route (for example the VIPRE reporting link). Where messages were being statically SMTP-forwarded out of the managed environment (for example into third‑party CRM systems), investigators observed that Microsoft Defender and other perimeter policies did not inspect those forwarded messages and handled incidents by blocking or handling mail at the forwarding destination or by changing forwarding configuration so mail flowed through organisational filtering. For inbound-delivery failures, affected accounts were found on an internal blocklist and were removed/unblocked; inbound delivery resumed. Changes implemented were limited to mailbox blocked-sender lists, the internal blocklist, mail-filtering blocklists or forwarding configuration rather than broad perimeter policy changes.

Technicians confirmed the Jungle Mail site mapping (it appeared as "Default Site" in the system) and added the requested sender e-mail (cpod@iu.org) to the Jungle Mail allowed sender list. The user verified sending worked. After a subsequent user request, the site sender was changed to growth@iu.org and the allowed-sender list was updated accordingly.

Incidents were traced to automated content‑detection/DLP controls that either applied Microsoft Purview Message Encryption at transport or quarantined outbound messages at an external gateway. Where Purview encryption was applied, messages were confirmed encrypted (not corrupt) and recipients could open attachments by using the Purview 'Read the message' flow and the one‑time code authentication option. Where third‑party gateways quarantined messages (example: Fusemail), affected messages were identified as expected false positives from test data and were released or ignored after confirmation. Behaviour varied by scanning layer (encryption applied at transport/DLP versus quarantine at an external gateway). Several incidents were attributable to non‑PCI detection patterns — for example, one case involved automated classification of content as a UK NHS number (the sender believed purchase‑order numbers were being misclassified), and that ticket was closed with no documented policy change. Temporary/test recipient addresses increased false‑positive risk and frequently explained quarantine/encryption during trials.

Investigation of mail headers and web‑form submission logs traced the bounce notifications to automated/spoofed submissions through the site’s public web forms that used forged/non‑existent envelope‑from addresses. The team confirmed there were no matching internal accounts or legitimate sends and classified the events as external spam/hacking attempts rather than mailbox compromise. The incident was resolved by documenting the origin and treating the incoming bounces as non‑legitimate, with monitoring retained on the affected inbox and web‑form logs for recurrence.

Investigators confirmed the affected messages originated from external senders and that delivery failures were caused by mailbox acceptance/forwarding restrictions or misconfigured forwarding rules. Two resolution patterns were recorded. In cases where organisational policy explicitly disallowed forwarding or acceptance of mail from one external address to another (for example certain helpdesk addresses), the incident was closed administratively by informing senders of the policy and directing them to the central intake channel. In cases where mailbox-level rules or forwarding configurations were blocking external-origin messages (for example invoices forwarded to an OCR tool), the issue was resolved by reviewing the target mailbox and account configuration, removing or correcting rules that prevented external messages from being accepted or forwarded, and monitoring mail-flow logs to confirm messages reached the downstream system. Where spam/security filtering contributed, the corrective changes to rules allowed external messages to be delivered to the intended mailbox or processing pipeline.

The case was escalated to the specialist team, which triggered the platform's sender verification message to the user's email address. The user completed the verification by confirming the verification email, and after the sender address was marked verified the error no longer occurred and Salesforce was able to send the emails successfully.

The team blocked both meazurelearning.com and proctoru.com for the student address space by creating scoped controls that applied only to student mailboxes. An Exchange Online mail flow (transport) rule was implemented to match messages from the two sender domains and to reject/quarantine inbound mail when the recipient address belonged to the student domains (iu.org and iu-study.org); employee mailboxes were excluded by scoping conditions. The domains were also added to the Microsoft 365 tenant Allow/Blocklist as blocked sender domains and Defender for Office 365 anti‑spam policy settings were adjusted to quarantine remaining hits. The change was scheduled and activated on 2025‑06‑23 06:00 and administrator release paths were left available for any false positives.

The incident was escalated to mail specialists who reviewed transport logs and internal block‑list entries. They identified that the recipient account had been mistakenly placed on an internal recipient block‑list, removed the recipient from the block‑list, and confirmed the sender could resend the message. Normal outbound delivery resumed and the ticket was closed.

Mail delivery was restored after the Care system re-established SASL authentication to MX1 and the source IP used by simovative-care-sbm was removed from fail2ban's blocklist / allowlisted. Postfix resumed accepting SMTP logins for simovative-care-sbm (sasl_method=LOGIN, sasl_username entries appeared again) and outbound message flow from the Care system returned to normal.

DotDigital support confirmed iu.org was on their global suppression list. Removal required confirmation from the domain owner: IU IT (domain owner for iu.org) needed to contact support@dotdigital.com to confirm ownership/authorization. Once DotDigital received that confirmation they would remove iu.org from the global suppression list and allow sends to resume. At the time of the ticket, the domain-owner confirmation and removal had not yet been completed.

Mail and spam‑filter logs were reviewed for messages from vimeo.com. Two recent messages from Vimeo Support (both titled '[Vimeo] Re: Subscription receipt') were located and had been successfully delivered to digital@libf.ac.uk. The user was informed that the messages were not being blocked by the perimeter filters and no whitelist or filter changes were required.

The investigation showed the DocuSign messages had been addressed to an incorrect email. The recipient address was corrected and the messages were replayed/resent through VIPRE to the proper mailbox, after which delivery was restored.

Support examined the item and identified it as a rights‑protected message but was unable to open or display its contents from the user's Inbox. No technical remediation or decryption steps were recorded in the ticket. Support advised treating unexpected rights‑protected messages as potential phishing and requested the mailbox location plus subject and sender metadata for further investigation.